[00:04.170 --> 00:10.050]  Okay, hello everyone. My name is Joe Slowik, and I'm going to be talking about something I call
[00:10.050 --> 00:18.850]  mission kill, focusing on process targeting in ICS attacks. So getting into that first,
[00:18.850 --> 00:26.590]  who am I? So currently I am a adversary hunter, a fancy way of saying threat intelligence I suppose,
[00:26.590 --> 00:32.870]  working at Dragos, focusing on industrial control system threats and threat activities.
[00:32.870 --> 00:39.390]  I also do some cyber threat intelligence training through a side gig called Paralys.
[00:39.390 --> 00:43.270]  If you're hanging around the Blue Team Village, you'll see me with a workshop on cyber threat
[00:43.270 --> 00:50.070]  intelligence later today. But in addition to my current time working with Dragos on ICS threats,
[00:50.070 --> 00:55.290]  I formerly led the incident response team at Los Alamos National Laboratory and did some
[00:55.290 --> 01:01.150]  sidery things for the U.S. Navy as an officer back in the day. But enough about me, we really
[01:01.150 --> 01:08.010]  want to get to our agenda for today. And along those lines, we're going to start with just a
[01:08.970 --> 01:18.070]  definition of what an attack means. There's a lot of confusion around the word, and so just get a
[01:18.070 --> 01:24.650]  common conception of what the term means in the context of ICS events. And then review three
[01:24.650 --> 01:29.130]  process targeting incidents from the past few years and what those teach us and the consequences
[01:29.130 --> 01:36.230]  of seeing adversaries migrate into a more refined or a more focused way of trying to
[01:36.230 --> 01:41.710]  impact control system environments. And conclude with defensive options and implications for
[01:41.710 --> 01:48.430]  what it is that asset owners and operators need to do in order to meet this type of or category
[01:48.430 --> 01:55.960]  of threat. So first to define attack, principally I'm looking at attack as being those deny,
[01:55.960 --> 02:02.440]  destroy operations. So just simply scanning a device, sending a phishing message, don't really
[02:02.440 --> 02:08.500]  constitute attacks. These can come into play in terms of certain preparatory actions, but trying
[02:08.500 --> 02:17.220]  to determine what is simply a route to economic espionage versus what is a precursor to an attack
[02:17.220 --> 02:23.520]  really depends upon being able to discern or identify adversary intent. And short of being
[02:23.520 --> 02:28.240]  able to read minds, it's very hard to do that. So really for the purposes of this discussion,
[02:28.240 --> 02:34.860]  we're really only talking about those sorts of incidents where there has been noticeable process
[02:34.860 --> 02:43.000]  disruption, degradation, or denying control over an industrial process. So looking at that,
[02:43.000 --> 02:47.600]  we can map this and there are several ways of doing this. There's the ICS specific kill chain,
[02:47.600 --> 02:52.100]  as well as the various other kill chains that are out there. Since we can't just have one,
[02:52.100 --> 02:58.340]  we need multiple. But really looking at a sequence of events going from typically breaching
[02:58.740 --> 03:04.640]  a victim's IT network, identifying points of contact with the industrial environment,
[03:04.640 --> 03:09.400]  enumerating and categorizing that environment in order to determine what sort of capabilities
[03:09.400 --> 03:18.000]  are necessary in order to interact with or make some change or disruptive effect within that
[03:18.000 --> 03:22.660]  environment, and then finally being in a position to deliver effects on objectives.
[03:22.660 --> 03:28.380]  So a sequence of events that are interdependent, that if you fail in one, you essentially fail in
[03:28.380 --> 03:35.860]  all, that defines what it is required in order to execute something disruptive or destructive
[03:35.860 --> 03:41.840]  within an industrial environment. And so with that in mind, looking at a lot of headlines,
[03:41.840 --> 03:46.900]  we see things that are mentioned as attacks that really don't meet that bar. Whether we have items
[03:46.900 --> 03:54.500]  like the infamous dam, New York dam incident from almost 10 years ago now, to items like the
[03:54.500 --> 04:00.900]  Baku-Sehan-Tbilisi pipeline incident, or even just plain made up items like in the wild ransomware
[04:00.900 --> 04:07.400]  that was a company tech demo and whatnot, that we see the word attack thrown about quite frequently
[04:07.400 --> 04:13.800]  but done so in ways that really don't align well with a conception of what an attack really means
[04:13.800 --> 04:21.820]  or where the implications are quite real. We do, however, see general attacks that impact ICS.
[04:21.820 --> 04:26.000]  So whether we're looking at something like the Shamoon event or the sequence of Shamoon events
[04:26.000 --> 04:33.800]  since the first one in 2012, moving on to items like there was a recent very interesting event
[04:33.800 --> 04:37.960]  that took place in the United States just last year, where there was a denial of service condition
[04:37.960 --> 04:44.000]  on a router that inhibited control over a wind farm for a period of time. But while concerning,
[04:44.000 --> 04:49.480]  it seemed very untargeted. And then getting into things like various ransomware strains that migrate
[04:49.480 --> 04:55.140]  into and have some impact on industrial operations. While all of these are very concerning,
[04:55.140 --> 05:03.080]  they're also somewhat dumb or very untargeted and kind of sloppy in impact. They're not terribly
[05:03.080 --> 05:10.620]  focused and not really taking into consideration the nature of or the specifics of the targeted
[05:10.620 --> 05:15.880]  industrial environment or the underlying process. Because today, what we want to talk about is a
[05:15.880 --> 05:21.400]  more focused type of attack that I refer to as process targeting, where instead of just blindly
[05:21.400 --> 05:26.560]  looking to disrupt whatever is reachable within an environment, attackers instead focus on a
[05:26.560 --> 05:31.960]  specific stage or aspect of an industrial process. And this can be technical, such as looking for
[05:31.960 --> 05:37.480]  specific equipment or software, targeting a known vulnerability or something along those lines,
[05:37.480 --> 05:43.060]  or it could be operational. So understanding what the sequence of events required for an industrial
[05:43.060 --> 05:49.740]  process, such as a manufacturing line that goes through three distinct states, and knowing which
[05:49.740 --> 05:55.580]  is a critical path node that if it's disrupted, it results in the entire line being brought down,
[05:55.580 --> 06:00.520]  represents a more operational way of looking at things and targeting those sorts of weak points.
[06:00.520 --> 06:05.760]  So we're really trying to move away from the discussions on indiscriminate wiping, ransomware,
[06:05.760 --> 06:11.800]  worms, etc., which define most of the industrial impacting events that we've seen thus far.
[06:11.940 --> 06:15.800]  But the thing is, don't just describe all of the industrial events that we've seen to date,
[06:15.800 --> 06:22.100]  because there are a subset of industrial impacting events, some in cyber, but one that's actually
[06:22.100 --> 06:25.840]  physical that I think presents some very important lessons. And so I'm going to bring that into the
[06:25.840 --> 06:31.540]  discussion today, that represent true process targeting for impacts and industrial control
[06:32.280 --> 06:38.420]  environments. So we'll talk to the 2016 Ukraine event, which involved the crash-over-rod malware,
[06:38.420 --> 06:45.020]  also referred to as Indestroyer, the 2017 Saudi Arabia incident that involved the use of the
[06:45.020 --> 06:49.800]  Triton or Trisys malware, and then talk about something that happened in Saudi Arabia in 2019
[06:49.800 --> 06:55.560]  that wasn't cyber in origin, but really emphasizes how attackers are evolving when it comes to
[06:55.560 --> 07:02.140]  operating in industrial spaces. So first, the crash-over-ride incident. This was something that
[07:02.140 --> 07:07.400]  was briefed at Black Hat a couple of years ago between Mike, myself, and some Draco's colleagues,
[07:07.400 --> 07:13.380]  as well as Anton Cherpenov and Robert Lepofsky of ESET. An interesting event in that it represented
[07:13.380 --> 07:21.280]  the second cyber event impacting electric operations in Ukraine after the 2015 incident,
[07:21.280 --> 07:27.160]  but the 2016 event was a little bit more interesting because it represented a technical
[07:27.160 --> 07:33.640]  evolution in that it introduced a specific piece of malware with capabilities for manipulating
[07:33.640 --> 07:42.980]  the distribution, well, transmission operations within a substation in order to cause a
[07:42.980 --> 07:47.960]  disruption of the delivery of power. So the way that this attack worked is first, penetrate the
[07:47.960 --> 07:53.120]  environment and place malware on computers that can communicate to the field devices that actually
[07:53.120 --> 07:57.740]  control the breakers, and schedule that malware in order to open breakers at the target transmission
[07:57.740 --> 08:06.600]  site to do a sort of coordinated effort. And then there was some after-effect limited system wipe
[08:06.600 --> 08:11.800]  and some disabling events on infected machines that induced the loss of at least logical or
[08:11.800 --> 08:17.240]  state of control in the specific environment. And then there was this thing that at least at the
[08:17.240 --> 08:21.940]  time, and I've since analyzed this quite extensively in my presentation at the ICS Village
[08:21.940 --> 08:26.680]  last year actually, as well as in a subsequent white paper, on a protective relay denial of
[08:26.680 --> 08:30.640]  service that took place post-attack, which actually starts to become more significant
[08:30.640 --> 08:36.400]  when you look at this attack in terms of process dependencies. Because when we start looking back
[08:36.400 --> 08:43.440]  at 2015, the attackers used a wiper ostensibly to delay recovery in 2015, that we will disable all
[08:43.440 --> 08:48.060]  the SCADA workstations, all the engineering workstations, in order to inhibit the ability
[08:48.060 --> 08:54.280]  to restore operations in an effective and efficient way. But from the 2015 attack, it was proved that
[08:54.280 --> 09:00.340]  the operators in question were quite happy and willing to rapidly shift into manual operations
[09:00.340 --> 09:05.640]  in order to restore electric service as quickly as possible. And we can assume that the attackers
[09:05.640 --> 09:10.660]  weren't stupid, and there are significant pieces of evidence that have been reported publicly,
[09:10.660 --> 09:14.860]  as well as a lot of things I've written privately, that the attackers in these incidents, if not,
[09:14.860 --> 09:19.220]  are the same, or at least are very much tightly linked, that they took note and that the wiper
[09:19.220 --> 09:23.880]  functionality in 2016 really seems kind of superfluous if you know that the operators
[09:23.880 --> 09:29.720]  are going to go out to the transmission yard and start closing breakers manually. So other
[09:29.720 --> 09:34.020]  than just being an asshole and wiping computers and making restoration just more painful in the
[09:34.020 --> 09:38.980]  long term, why would you do this? Well, it seems that instead the wiper was intended for other
[09:38.980 --> 09:44.420]  purposes, that rather than to inhibit restoration, because you know that the operators are going to
[09:44.420 --> 09:49.920]  get into manual operations, instead the wiper seems more aligned with eliminating logical view
[09:49.920 --> 09:55.300]  and control of the SCADA environment. And that brings us to protective relays, because that
[09:55.300 --> 10:00.220]  denial of service condition on protective relays becomes fairly significant when you realize what
[10:00.360 --> 10:05.720]  a protective relay does in the context of electric utility operations. So especially a digital
[10:05.720 --> 10:12.880]  protective relay is a smart device that works to ensure the process, maybe not necessarily safety,
[10:12.880 --> 10:19.620]  but certainly process control and certain degrees of process protection to make sure that
[10:19.620 --> 10:24.620]  fluctuations in electric distribution and transmission operations don't propagate beyond
[10:25.220 --> 10:30.640]  the relay operations in order to induce potential physical damage to electric
[10:30.640 --> 10:35.560]  distribution, transmission, or even generation gear. So looking at this is that we see protective
[10:35.560 --> 10:41.720]  relays as being a significant aspect of electric operations at multiple stages of the electric
[10:41.720 --> 10:47.760]  utility landscape. And while you can operate without them, it induces a certain level of
[10:47.760 --> 10:53.040]  risk in that fluctuations in normal fluctuations is the part of electric operations, let alone
[10:53.040 --> 11:00.180]  the introduction of potential disasters, natural or engineered, means that with the absence of relay
[11:00.180 --> 11:05.700]  protection, anomalous events would propagate beyond that protective layer to start impacting
[11:05.700 --> 11:12.140]  equipment directly, thus creating the preconditions for physical equipment damage. So looking at the
[11:12.140 --> 11:17.400]  event in Ukraine, the Siemens SuperTech denial of service is pretty interesting in that
[11:17.400 --> 11:22.280]  it doesn't take the device offline, but rather the denial of service wipes all the protective logic
[11:22.280 --> 11:28.100]  from it. It's one of those, this is a feature as opposed to a bug, in that it's used to free up
[11:28.100 --> 11:33.880]  memory to allow for a firmware upgrade or reprogramming of the device. So the device is
[11:33.880 --> 11:39.500]  still network accessible, it looks powered on, so if you're running through the yard trying to
[11:39.500 --> 11:43.520]  figure out what's going on or through the control room, it might look like the device is still up
[11:43.520 --> 11:49.980]  and running, but all the actual protection logic is removed, so it's not doing its job. And it's a
[11:50.760 --> 11:55.340]  trivial attack to execute just by setting a single UDP packet within the environment. It is worth
[11:55.340 --> 11:59.360]  noting that there was an endingness mistake in the malware. Not sure if they were counting on
[11:59.360 --> 12:04.100]  this being translated in some fashion, although working in a lab environment, not quite sure how
[12:04.100 --> 12:08.080]  this was supposed to have worked, but it doesn't look like the payload would have been delivered
[12:08.080 --> 12:12.240]  properly, at least in the actual attack. And this is one of a number of mistakes that were made as
[12:12.240 --> 12:18.440]  part of the crash override event. But even though it didn't work quite as to the extent or in the
[12:18.440 --> 12:24.680]  fashion that the attackers wanted to, the intentions and the capabilities deployed in the 2016 Ukraine
[12:24.680 --> 12:29.860]  incident show a much more ambitious event than what we saw in 2015, in that the attackers
[12:29.860 --> 12:36.720]  induced a widespread outage and a loss of view condition through that wiping aspect, and then
[12:36.720 --> 12:41.420]  removed line protection from transmission operations. Now, removing line protection on a
[12:41.420 --> 12:47.880]  de-energized line makes no sense when you think about it, but if you're anticipating that operators
[12:47.880 --> 12:51.540]  will rush to restore operations irrespective of their ability to ascertain the process safety and
[12:51.540 --> 12:56.220]  protection of the environment, now you're setting up a staged attack where there's potential
[12:56.220 --> 13:01.860]  physically destructive consequences when you restore power to those de-energized lines in the
[13:01.860 --> 13:08.400]  absence of process protection. So while it didn't work as intended, crash override was appears as
[13:08.400 --> 13:13.660]  though it was designed to try to achieve physical process destruction within the context of electric
[13:13.660 --> 13:18.980]  transmission operations that would have had disruptive effects lasting potentially months
[13:19.690 --> 13:27.920]  in order to try to restore, recover, and ultimately likely replace damaged gear. And a lot of this
[13:27.920 --> 13:32.280]  comes from knowing both the combination of how the operators in question worked within their
[13:32.280 --> 13:37.230]  environment as well as the importance of protective relays for electric operations.
[13:38.180 --> 13:44.020]  Moving on to 2017, we had the Triton Trisis incident at a petrochemical facility in Saudi
[13:44.020 --> 13:50.180]  Arabia. And there was much discussion at the time about Triton Trisis as being malware that can kill
[13:50.180 --> 13:55.700]  and who was behind it. Is it Iran? Is it Russia? Or is it some other entity? But a lot of the
[13:55.700 --> 14:00.760]  discussion really masked some of the subtleties and really quite interesting technical details
[14:00.760 --> 14:07.540]  around what Trisis was capable of and how it would work as part of a overall attack sequence.
[14:07.540 --> 14:12.680]  Because again, similar to what we saw in 2016, Triton Trisis was not a bolt from the blue but
[14:12.680 --> 14:19.000]  rather the end result, well not even the end result as we'll see shortly, in a sequence of
[14:19.000 --> 14:24.040]  events to achieve physical process disruption or destruction within the victim environment.
[14:24.040 --> 14:29.640]  So we have a combination of items of repeated credential harvesting and reuse to pivot around
[14:29.640 --> 14:35.000]  the environment and to replay access through legitimate VPNs in order to get remote access
[14:35.000 --> 14:39.880]  into the ICS environment, continuing to pivot through credential capture until the attacker
[14:39.880 --> 14:45.140]  is able to get direct communication to a safety instrumented system on which Trisis could be
[14:45.140 --> 14:49.240]  deployed. And that's an interesting part and requires us to understand what a safety instrumented
[14:49.240 --> 14:54.540]  system is within the context of industrial operations generally and petrochemical facilities
[14:54.540 --> 15:01.440]  specifically. Because safety systems, while they don't ensure that nothing bad ever does happen,
[15:01.700 --> 15:07.040]  a safety instrumented system typically acts as sort of an emergency control system in parallel
[15:07.040 --> 15:14.200]  to the basic or operator controlled environment, such that in the event of a hazardous or dangerous
[15:14.200 --> 15:19.860]  set of conditions within the plant environment, that automated controls are put into place to
[15:19.860 --> 15:25.960]  ensure an easier or less physically disruptive recovery of the plant environment to minimize
[15:25.960 --> 15:32.560]  damage, disruption, and facilitate recovery. Now there are certainly additional safeguards within
[15:32.560 --> 15:37.540]  plant environments from blowout valves and pressure release valves and other sorts of items
[15:37.540 --> 15:41.680]  that act as engineering layers of safety control, but these start getting into
[15:41.680 --> 15:47.480]  more difficult circumstances for recovery and may have potentially hazardous conditions of
[15:47.480 --> 15:51.920]  themselves, like if you're venting product or even high pressure or high temperature steam,
[15:51.920 --> 15:56.220]  in order to reduce pressure in an environment that could lead to physically hazardous conditions.
[15:56.300 --> 16:00.460]  So while just because you remove the safety layer doesn't mean that you're setting up a plant for
[16:00.460 --> 16:05.640]  absolute tremendous levels of destruction, it still makes for a very hazardous environment
[16:05.640 --> 16:11.040]  where potentially nasty things can take place. If we start looking at trite and trisis, it becomes
[16:11.040 --> 16:16.380]  important to note that the intrusion itself wasn't just focused on the safety layer, but in talking
[16:16.380 --> 16:21.480]  with the incident responders who worked on the event, the compromise took place through both
[16:21.480 --> 16:26.560]  the safety layer as well as within the plant distributed control system environment. Using
[16:26.560 --> 16:33.920]  those compromises in parallel, a modification of safety settings means that you can have a
[16:33.920 --> 16:38.760]  manipulation on the DCS side that could cause a hazardous condition and then allow it to propagate
[16:38.760 --> 16:43.200]  through the safety layer in order to produce a hazardous effect within the environment in
[16:43.200 --> 16:49.720]  question. And this combined intrusion and the interdependency between the two requires some
[16:49.720 --> 16:53.620]  understanding and knowledge of how these different items interact with each other and what sort of
[16:53.620 --> 16:59.720]  changes or what sort of actions you can take that would allow for a cyber action to propagate into
[16:59.720 --> 17:05.300]  actual physical disruption as opposed to merely a plant denial of service. Because what's interesting
[17:05.300 --> 17:10.220]  about this is that trite and trisis, kind of like the 2016 event, didn't work, at least not as the
[17:10.220 --> 17:15.340]  attackers intended. So whereas it looks like the intended attack was to modify the sys to eliminate
[17:15.340 --> 17:21.120]  the safety layer, then leverage compromise of the DCS in order to produce a dangerous state that
[17:21.120 --> 17:25.880]  would then propagate beyond the safety layer to cause physical process disruption, instead of the
[17:25.880 --> 17:32.000]  time of installation of the trisis malware, which happened not just once but twice, at least twice,
[17:32.000 --> 17:37.020]  within the environment, that a error or something else within how the malware was put together
[17:37.020 --> 17:43.040]  caused the safety system to trip. And as a result, the plant shut down, which is still very disruptive
[17:43.040 --> 17:47.140]  and not a nice thing and cost a lot of money, but doesn't result in the sort of damage that would
[17:47.140 --> 17:51.480]  have happened had this attack actually worked as it looked like it was designed or intended to
[17:51.480 --> 17:56.260]  be carried out. So again, attackers are getting smarter in terms of knowing what sort of things to
[17:56.260 --> 18:00.640]  look for within industrial environments to sort of maximize damage, but still showing that they
[18:00.640 --> 18:05.580]  have a ways to go before being able to do so successfully or at least on a consistent basis.
[18:05.860 --> 18:09.040]  Which brings us to something very interesting and a little bit more blunt than some of the
[18:09.040 --> 18:14.760]  cyber operations we've been talking about so far. Now in September of 2019, there was a very
[18:14.760 --> 18:20.340]  interesting event that took place in Saudi Arabia, again Saudi Arabia, where there was a drone and
[18:20.340 --> 18:29.380]  missile strike on two facilities in Saudi Arabia, the petrochemical facility at Abqaiq and the oil
[18:29.380 --> 18:35.400]  production facilities at the Kurias field within the country. So certainly very alarming, very
[18:35.400 --> 18:39.540]  concerning, but what the hell does this have to do with cyber and why are you bringing this up, Joe?
[18:39.540 --> 18:45.240]  Well, the reason is that, for one, this represents the continuation of a series of events, both
[18:45.240 --> 18:51.160]  cyber and physical, against Saudi oil infrastructure from the Shamoud events to multiple physical
[18:51.160 --> 18:57.220]  disruptive and similar drone strikes both on cross-country pipeline operations as well as oil
[18:57.220 --> 19:02.360]  and gas production facilities. But what makes the September 2019 incident especially interesting
[19:02.360 --> 19:08.260]  is that it was very focused on a specific aspect of Saudi oil and gas operations that show a level
[19:08.260 --> 19:13.380]  of knowledge about how the Saudi oil and gas sector works and going back to the idea of process
[19:13.380 --> 19:19.520]  specific understanding and targeting. Because when we look at Abqaiq, it is the world's largest oil
[19:19.520 --> 19:24.620]  processing and crude stabilization facility. Essentially, Abqaiq serves as the linchpin for the
[19:24.620 --> 19:30.600]  entire Saudi... well, for the majority of Saudi oil production in sweetening otherwise sour crude
[19:30.600 --> 19:37.340]  so that it is easier to sell and more acceptable to world markets. Essentially, if you take out
[19:37.340 --> 19:43.780]  the Abqaiq facility or its ability to operate, the ability for Saudi Arabia to produce oil that
[19:43.780 --> 19:49.340]  the market desires becomes severely degraded and thus producing significant economic disruption
[19:49.340 --> 19:55.220]  as a result of physical disruption. Because looking at the sweetening operations or the
[19:58.120 --> 20:05.220]  desulfurization of removal of sulfur from crude oil, it's a very complex chemical operation that
[20:05.220 --> 20:10.380]  requires a significant investment in equipment, fairly large physical footprint for plant
[20:10.380 --> 20:16.100]  operations, and as a result, something that represents a fairly big target. And it's been
[20:16.100 --> 20:20.120]  the one that's been targeted at least in the context of Abqaiq several times previously but
[20:20.120 --> 20:25.540]  through rather blunt measures such as car bombs and other operations. Whereas the 2019 strike
[20:25.540 --> 20:31.700]  showed a very specific targeting because if we look at after action reports of the damage, we see
[20:31.700 --> 20:37.140]  that a lot of the primary focus of the attack wasn't on things like oil storage facilities
[20:38.140 --> 20:44.060]  or pumping and transportation infrastructure, but rather on the vessels and cracking facilities
[20:44.060 --> 20:51.660]  required to perform the hydro desulfurization of crude oil to make it acceptable and for the market
[20:51.660 --> 20:56.880]  or able to export it. So again, a very focused attack on a very specific aspect of the Saudi
[20:56.880 --> 21:01.920]  industry that shows an understanding of a critical process node or path dependency
[21:01.920 --> 21:05.880]  within Saudi oil operations that could allow for a significantly
[21:08.040 --> 21:13.680]  magnified impact as a result of just attacking one physical component of Saudi oil and gas
[21:13.680 --> 21:19.680]  infrastructure. So targeting hydro desulfurization facilities would significantly limit Saudi ability
[21:19.680 --> 21:24.420]  to export oil to market, and it did for a while, and there was significant effort placed into trying
[21:24.420 --> 21:29.640]  to restore these operations as rapidly as possible to try and recover. But as a result, the attacker
[21:29.640 --> 21:35.420]  was able to maximize a fairly limited strike by making sure they targeted just the right facilities
[21:35.420 --> 21:40.120]  in order to cause a magnified impact far out of scope, or at least seemingly
[21:42.260 --> 21:47.760]  out of scope, or at least beyond the immediate impacts of just physical process disruption. So
[21:47.760 --> 21:52.420]  understanding how these things tie together enables for a much more powerful, much more
[21:52.420 --> 21:58.160]  impactful attack than just simply lobbing bombs into the Abqaiq facility and hoping for the best.
[21:58.360 --> 22:02.380]  So where does that take us? Well, it shows that attackers are starting to get a little bit smarter
[22:02.380 --> 22:06.620]  in what they're shooting for when it comes to trying to disrupt industrial environments, whether
[22:06.620 --> 22:12.640]  that comes through cyber operations like we saw in the 2016 Ukraine event and the 2017 Saudi event,
[22:12.640 --> 22:19.240]  as well as through physical operations such as the Abqaiq drone and missile strike. Because what we're
[22:19.240 --> 22:24.920]  seeing is that adversaries are learning about how these operations work, and that increased knowledge
[22:24.920 --> 22:29.440]  yields an understanding of functional dependencies within these environments that allow us for
[22:29.440 --> 22:34.460]  adversaries to engage in focused targeting so that they can increase the effectiveness and
[22:34.460 --> 22:39.600]  the disruptive capability of strikes, no matter how they happen to be executed within plant
[22:39.600 --> 22:44.200]  environments. And we're looking at these focus points on the three items that we covered in the
[22:44.200 --> 22:49.580]  examples today. Process protection, the ability to make sure that industrial environments remain
[22:49.580 --> 22:55.680]  in a fashion that avoids physical damage and disruption to the equipment in question.
[22:55.680 --> 23:01.600]  Process safety, to make sure that equipment is not able to or at least has sufficient safeguards
[23:01.600 --> 23:06.320]  in place so as not to risk the safety or effectiveness of equipment or potentially
[23:06.320 --> 23:10.940]  causing harm to personnel within the plant environment. As well as process dependencies,
[23:10.940 --> 23:16.760]  looking at how critical a single facility like Abqaiq would be to the overall export of petroleum
[23:16.760 --> 23:22.060]  products for the Kingdom of Saudi Arabia. And the risks of this and the implications are that
[23:22.060 --> 23:27.620]  attackers, by being able to focus on specific aspects of industrial operations, open up very
[23:27.620 --> 23:33.320]  interesting avenues for what kind of damage they can cause. Everything from making sure they could
[23:33.320 --> 23:39.300]  cause more focused and potentially longer lasting process disruption, thus increasing downtime,
[23:39.300 --> 23:44.220]  towards in scarier items like a potential loss of life scenario, which may have manifested had
[23:44.220 --> 23:49.500]  crisis actually worked out as it was intended, or physical damage like was the which was the
[23:49.500 --> 23:54.760]  likely intention in the 2016 Ukraine event. So looking at this, we're seeing adversaries
[23:54.760 --> 24:00.720]  evolve over time from rather blunt and somewhat simplistic attacks like IT-based wipers,
[24:00.720 --> 24:05.560]  such as the Shamoon events and some other incidents where just deploy something that
[24:05.560 --> 24:13.640]  network and cause as much disruption as you can in a fairly untargeted and widespread fashion,
[24:13.640 --> 24:20.320]  then getting into more untargeted disruption, just trying to disconnect processes and inhibit control,
[24:20.320 --> 24:25.020]  something like we saw with the 2015 Ukraine event, and then getting into more advanced and
[24:25.020 --> 24:30.520]  more specific targeting, such as the focus on protective relays in 2016, the focus on safety
[24:30.520 --> 24:37.600]  systems in 2017, or the focus on hydro desulphurization operations in the 2019 kinetic
[24:37.600 --> 24:44.280]  strike. What we do about this is an open question, though, because when we look at defense in a
[24:44.280 --> 24:48.880]  classical sense, we usually think of throwing up walls and trying to keep adversaries out.
[24:48.880 --> 24:53.660]  And while this is not necessarily a bad thing, and we certainly want to keep adversaries out,
[24:53.660 --> 24:59.360]  this is a very limited view and not necessarily helpful in trying to really adapt with how
[24:59.360 --> 25:03.780]  adversaries are shifting when it comes to trying to impact industrial environments.
[25:03.900 --> 25:07.840]  Because looking at industrial environments, we have the combination of not just
[25:07.840 --> 25:14.440]  IT-based or IT-like equipment, which is amenable to IT-like controls, but also combined with that,
[25:14.440 --> 25:18.820]  the physical process environment, both in terms of what the environment is designed to do,
[25:18.820 --> 25:24.840]  as well as the implications of undesired or unintentional modifications to that environment
[25:24.840 --> 25:30.320]  that can cause disruption and potentially even damage. So instead, we need to have process-aware
[25:30.320 --> 25:35.580]  defense as part of ICS operations, where traditional IT-centric defense certainly
[25:35.580 --> 25:39.940]  forms a major plank of what we're trying to do, because we have lots of information systems
[25:39.940 --> 25:45.400]  that now reside within industrial environments. But we want to combine this with process-specific
[25:45.400 --> 25:52.120]  monitoring and analysis so that we can marry a logical view of the environment along with a
[25:52.120 --> 25:56.980]  physics-centric or process-centric view of just what's going on within the plant environment,
[25:56.980 --> 26:01.340]  so that we can ascertain things such as the status of process protection, process safety,
[26:01.340 --> 26:06.380]  or how different items of the overall process environment are interacting and what our IT
[26:06.380 --> 26:11.280]  visibility may indicate certain entities are trying to do within that environment. But also,
[26:11.280 --> 26:14.960]  we want to make sure that we're investing in resilience and recovery. This is always an
[26:14.960 --> 26:18.760]  uncomfortable topic, because it implies that bad things have already happened. But if we look at
[26:18.760 --> 26:25.680]  events like the 2016 and 2017 events, we need to make sure as ICS defenders and ICS operators
[26:25.680 --> 26:29.840]  that we have the capability of not only identifying what changes have taken place within
[26:29.840 --> 26:34.660]  the operating environment, such as the removal of process protection and process safety, but also
[26:34.660 --> 26:40.120]  have a way of ascertaining what those changes were and how to restore or recover from those changes,
[26:40.120 --> 26:45.880]  so that we're not just restoring availability in the sense of bringing processes back online,
[26:45.880 --> 26:51.120]  but also making sure that we're maintaining process integrity and that operations are
[26:51.120 --> 26:55.820]  restored to a known good and known safe state in order to make sure that we're not endangering
[26:55.820 --> 27:01.100]  operations or the personnel within that plant environment. And a key to doing this is making
[27:01.100 --> 27:05.140]  sure that we're improving visibility into industrial environments. So while we already
[27:05.140 --> 27:10.660]  see process data captured for operations purposes, we have data historians that do this job already,
[27:10.660 --> 27:15.460]  but we need to combine that with improved host and network visibility, much like what we've seen
[27:15.460 --> 27:20.420]  over the past five years in enterprise IT environments, to combine data sets to develop
[27:20.620 --> 27:29.340]  a full scope ICS aware visibility of both the IT and ICS specific aspects of an operating environment
[27:29.340 --> 27:35.220]  to truly understand and track what is going on within the control system environment, both for
[27:35.380 --> 27:40.440]  a defensive perspective, as well as to just understand purely what's going on, should we have
[27:40.560 --> 27:45.220]  a malicious insider or other entity begin making changes to the environment that could have
[27:45.220 --> 27:52.360]  significant or harmful repercussions. And then finally, we need to make sure that we're including
[27:52.360 --> 27:57.480]  planning for response and resilience. That means adapting or modifying the existing contingency
[27:57.480 --> 28:02.320]  planning that exists from an engineering perspective to incorporate cyber, not just in the
[28:03.040 --> 28:07.200]  ability to restore operations, but also do you have the tools and the capability
[28:07.200 --> 28:11.780]  to perform root cause analysis to see that a modification or an attempted modification
[28:11.780 --> 28:16.160]  was made to a safety system or the denial of service condition on the super tech
[28:16.160 --> 28:21.400]  protective relay. And this also involves a focus of effort on those critical path nodes
[28:21.400 --> 28:26.620]  that allows us to better allocate or smartly allocate resources on those sort of crown jewel
[28:26.620 --> 28:33.240]  processes around which the entire operation revolves around so that we make sure that we're
[28:33.240 --> 28:37.360]  taking care of the most important assets in our environment. And as a result of all of this,
[28:37.360 --> 28:41.820]  we should be able to allocate resources in such a fashion to facilitate rapid critical
[28:41.820 --> 28:46.420]  resource restoration in an incident to not just minimize downtime, but to make sure we're again
[28:46.420 --> 28:52.140]  restoring to a known good, known safe state instead of just blindly bringing operations back
[28:52.140 --> 28:57.280]  up and hoping for the best. Ultimately, we're really looking to try and build out a robust
[28:57.280 --> 29:01.340]  defense in depth where we're covering things certainly at the IT layer, but also bringing
[29:01.340 --> 29:08.000]  things into a multi-layered understanding visualization and visibility into control
[29:08.000 --> 29:13.660]  system environments to track not just items like opportunistic ransomware or IT wipers,
[29:13.660 --> 29:19.080]  but also getting into process specific targeting and modifications that could lead to far more
[29:19.080 --> 29:23.520]  serious effects and building that all into an industrial focused and industrial aware
[29:23.520 --> 29:29.220]  security program. So with that, I'm right at time. I believe these slides will be posted
[29:29.220 --> 29:35.200]  somewhere. There's just a selection of resources, both things that I've written as well as from
[29:35.980 --> 29:39.960]  peers from ESET and FireEye and some of the events that we talked about today.
[29:39.960 --> 29:44.460]  But if we have some time, I can answer questions. I don't know how big of a
[29:44.460 --> 30:26.310]  cushion we're leaving between talks. Well, I hope this was interesting.
[30:26.310 --> 30:31.270]  Certainly feel free to reach out to me, email, Twitter, whatever works for you,
[30:31.270 --> 30:35.270]  as I'm always happy to discuss this and related items. I think it's quite fascinating,
[30:35.270 --> 30:41.570]  especially as we start looking into the more strategic and operations focused aspects of
[30:41.570 --> 30:45.450]  cyber events within industrial environments. It certainly is a lot more interesting than
[30:45.450 --> 30:49.570]  some of the things we see in IT environments, I think, but I'm a little biased there.
[30:50.550 --> 30:54.650]  But yeah, I don't know, Bryson, if you've got anything for me or anyone else?
[30:58.640 --> 31:00.840]  No, I think you're good. Thank you.
[31:04.610 --> 31:09.770]  Stop the share and I will let the program move on. I'll be hanging around within the
[31:09.770 --> 31:13.950]  Discord and elsewhere if anyone has thoughts that came up after the fact. But otherwise,
[31:13.950 --> 31:17.150]  I hope everyone enjoys the ICS Village, as I know I always do. Thank you.
